A previous similar attempt here #5683 you might also want to look at.

A previous similar attempt here #5683 you might also want to look at.

I'd rather see anything akin to this experimented with in content while the engine API is kept simple for now.

Conceptually I think I like the approach Tay took in his PR more for a couple of reasons (although the PR needed some more work from a technical standpoint).

The multiple component approach seems a little prone to user error to me, as you can have an arbitrary number of entities with component A, and arbitrary number of entities with component B, but only a single entity with both at the same time if any 2 or more component method is used. This is only validated when trying to find the entity, and not at spawn or with any modifications in-between.

This API leaves a lot of boilerplate to the user, which again seems error prone. In the PR linked above the singleton entities were automatically managed by the corresponding system on intialization.

The most common use case for singleton entities is as a sort of global, persistent datastorage for a specific system. So I think it makes more sense to tie the singleton status to an unique entity system corresponding to a component rather than a unique component. This may lead to some more flexibility in their use, and I don't see why the component itself has to be uniquely instanciated.

This API is a broad, general API meant to be used to scaffold a more specific one.

Tying anything to specific systems, or similar, is out of scope of this PR. Down the line I'll likely be implementing a Single<> query one can depend on, but right now I want this in the wild so I know what usecases end up actually looking like. I will not be designing an API for theoreticals when we do not have the power to then refactor and remove it easily later.